Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CAF::Download class: API proposal #110

Open
wants to merge 15 commits into
base: master
Choose a base branch
from

Conversation

stdweird
Copy link
Member

@stdweird stdweird commented Sep 19, 2015

There is no functional code here, only an API.
Based on #120
Part of #62

@stdweird stdweird added this to the 15.10 milestone Sep 19, 2015
@stdweird
Copy link
Member Author

@ned21 @jrha this is a PR to define the interface to use and have it reviewed/discussed before adding more work.

@stdweird
Copy link
Member Author

retest this please

@stdweird stdweird force-pushed the download branch 3 times, most recently from 6a5d68d to 1173570 Compare September 19, 2015 16:55
@documentation{
A string that represents a URL that can be handled by CAF::Download
Format: [auth+][method+]protocol://location
Protocols: http|file
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, yes and no. i'm confused myself about the naming with all the available combinations and tools.

there are a number of "scenarios" i want to support, but not sure splitting them up in protocol/method/auth makes sense

  • file: read from file (could require authentication like kinit+file, e.g. reading from afs (although i'm not sure if that isn't authorisation instead of authentication))
  • http: non-encrypted read from server using HTTP GET etc etc (could require authentication, like 'Basic auth', but is pretty non-safe, so there's no authentication called passwd or something).
  • plain http like MS uses this, i.e. by encrypting the payload, it becomes secure (authentication via decryption and encryption), and it requires a decrypting postprocessing otherwise the downloaded data is garbage. so calling this protocol http is maybe also not ok. i was thinking to put this under kinit+http (or gssapi+http) and detect the MS scenario via the same trick that CCM uses (the krbencrypt encoding https://github.com/quattor/CCM/blob/master/src/main/perl/Fetch/Download.pm#L96; i guess krbencrypt is something MS made up or is it a standardised name?)
  • https implies a valid client certificate, so x509+http is basically https (https without a valid client certificate is just not smart)
  • and there's the stuff i want to add for freeipa: http + authentication via spnego and kerberos, which is another flavour of kinit+http or gssapi+http, so a bit confusing with MS scenario, so i might call this kinit+httpn (HTTP Negotiate is a term used by microsoft for this, but they also support ntlm as authentication).
  • in the future, i would also add kinit+ipavault or other custom tools used to manage sensitive data

the first 3 are currently supported by ccm-fetch and ncm-download (afai understand the code). the 4th one is to address quattor/CCM#54, the 5th one is there so we don't have to try to setup our own secure datastore and be able to use existing tools.

the difference between kinit and gssapi mainly lies in the way the token is generated/managed: kinit/kdestroy binary or perl GSSAPI, but they both mean 'use kerberos`.

@stdweird stdweird modified the milestones: 16.4, 16.2 Feb 5, 2016
@stdweird stdweird removed this from the 16.4 milestone Mar 31, 2016
@jrha
Copy link
Member

jrha commented Jan 25, 2018

@stdweird where did this get to?

@jrha
Copy link
Member

jrha commented Apr 25, 2018

Still a good idea, several components still implement their own download mechanisms.

@ned21 ned21 changed the title Download: API proposal CAF::Download class: API proposal Apr 25, 2018
@jrha jrha added this to the 21.6 milestone Feb 17, 2021
@jrha jrha removed this from the 22.12 milestone Jan 3, 2023
@jrha jrha added this to the 25.next milestone Sep 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants